With the development of high-speed microcontrollers with on-chip memory, embedded software development and debugging has become increasingly challenging. The high signal speeds and lack of observability of the embedded system buses dictate the inclusion of on-chip debug (OCD) features to assist in the software development process. The cost of the OCD logic is connected with the level of intrusiveness accepted, i.e., to which extent the CPU can deviate from regular software execution during debugging.
Among the most fundamental debug features are program breakpoints. Program breakpoints involve halting the CPU when the software execution reaches a specific address. Once the CPU is halted, the debug tool can examine the state of system memory and registers in the CPU at this point, by issuing instructions to be executed on the CPU through a debug protocol. Once the examination is completed, the debug tool can return the CPU to normal mode, and execution will continue until the next breakpoint.
The two main approaches for implementing program breakpoints are known as hardware and software breakpoints.
Hardware breakpoints imply detecting when the CPU is about to execute a specific program address. This involves comparing the instruction bus address—or address attached to a fetched instruction, depending on computer architecture—to a specified address in a debug register written by the debug tool. Hardware breakpoints are non-intrusive, having virtually no impact on software execution until the breakpoint triggers. These breakpoints are thus suitable for the few debug situations where complete non-intrusiveness is demanded. However, they are costly, as they require a register and a comparator per breakpoint. For this reason, they are a limited resource in all on-chip debug systems.
Software breakpoints are intrinsically simpler than hardware breakpoints, and imply that the CPU executes a specific opcode as a breakpoint instruction, immediately halting the CPU and returning control to the debug tool. The debug tool can thus replace any opcode in the program memory with a breakpoint instruction, causing the CPU to halt at that address. This also means that the debug tool has to maintain a list of all software breakpoints inserted, and remember the original opcode at that location.
When returning from a software breakpoint, the debug tool has to execute the original opcode on the CPU while still in halt mode, and then return the CPU to normal operation. Software breakpoints are thus more intrusive than hardware breakpoints, as the breakpointed instruction has to be run in halt mode. However, most debug situations allow this intrusiveness, and the method has the huge benefit that an unlimited number of breakpoints can be implemented without additional hardware cost. For this reason, software breakpoints are normally preferred over hardware breakpoints, if supported by the memory technology.
How software breakpoints can be inserted depends on the memory technology of the microcontroller. The program memory can be either volatile or non-volatile. In either case, the program memory can usually be accessed by a debug tool, either directly (e.g. by JTAG commands) or indirectly, by halting the CPU and issuing instructions to access the program memory.
Volatile, i.e. RAM-based, memory is intrinsically read/writeable, while the write access to non-volatile memory depends on the technology. Flash program memory is quickly becoming the most popular non-volatile technology for embedded microcontrollers. Flash program memory can be erased, i.e. all memory cells set to ones, and written, i.e. selected memory cells cleared. The erase and write sequence takes a significant amount of time, typically many seconds if the entire Flash program memory needs to be programmed. Also, the sequence wears out the Flash program memory and can only be conducted a few thousand times before the Flash program memory can fail.
Software breakpoints work well in devices with RAM-based program memory, but have a distinct drawback in Flash program memory-based systems, as they require the memory to be erased and reprogrammed with the modified object code. This takes a considerable amount of time during the debugging, and can eventually wear out the Flash program memory, causing the device to fail permanently. A typical debug session involves adding several breakpoints progressively, as the failing code is narrowed down and identified.
Thus, the Flash program memory has to be reprogrammed several times for each debug session, and multiple debug sessions are required to debug large amounts of embedded code. This problem increases as the size of the embedded Flash program memory increases, both because the number of debug operations increase, and because the programming time increases. For this reason, a large amount of hardware breakpoints are required in Flash program memory microcontrollers, adding to the cost of the device, even if software breakpoints are supported. Therefore in summary, software breakpoints in prior art require the Flash program memory to be erased to insert the breakpoint and hardware breakpoints capable of detecting opcodes require separate debug registers to be implemented, and are more costly.
Accordingly, what is needed is a system and method for overcoming the above-identified problems. The present invention addresses such a need.